Staff engineer archetypes.

This is a draft guide for staffeng.com

Most career ladders define a single, uniform set of expectations for Staff Engineers. These career ladders attempt to identify the commonalities across many folks performing similar roles in their organization, but in the end these ladders are a tool that apply better against populations than people. In the case of Staff-plus engineers, career ladders paper over a number of distinct roles clustered under a single moniker.

The more folks I spoke with, the better their experiences clustered into four distinct archetypes, although these archetypes weren’t present across every company. The Tech Lead archetype did occur within every company, but if you look hard enough I’m sure you’ll find a company that has forgone even the Tech Lead. Other archetypes showed up sporadically or only after a company had scaled into the many hundreds or thousands of software engineers.

The four common archetypes of Staff-plus roles I encountered are:

This taxonomy is more focused on being useful than complete, but so far I’ve been able to fit every Staff-plus engineer I’ve spoken to into one of these categories, albeit certainly some folks fit more easily than others.

Examples: Diana Pojar, Dan Na, Duretti Hirpa, Ritu Vincent

Team Leads are the most common Staff archetype, and lead a team or small group of teams in their approach and execution. They’re comfortable scoping complex tasks, coordinating their team towards solving them, and unblocking them along the way. Team Leads often carry the team’s context and maintain many of the essential cross-team and cross-functional relationships necessary for the team’s success.

Earlier in their career they will have implemented their team’s most complex technical projects, but at this point they default to delegating such projects across the team. They do this both to grow their teammates and in acknowledgement that their team’s impact grows as their coding blocks shrink.

The Team Lead role is many folks their first experience as a Staff Engineer. A few forces conspire towards that result. First, the Team Lead role tends to develop early on within companies that have a strong concept of team, which is common among companies using agile methodologies, and most companies attempt an agile approach at some point. Another factor is that the day-to-day work of a Team Lead is most similar to the work you’d already be doing as a Senior Engineer, maybe it an intuitive transition.

To acknowledge a source of potential confusion, some companies use Team Lead as a title that you get promoted into instead of as a role. In this list of archetypes, the Team Lead is one approach to operating as a Staff Engineer, but it’s quite common to operate in the Team Lead role without having the impact expected of a Staff-level engineer. Indeed, you’ll find non-Staff engineers acting with the behaviors of every archetype. Being a Staff-engineer is not just a role, rather it’s the intersection of the role, your behaviors, your impact, and the organization’s recognition of all those things.

Examples: Joy Ebertz, Katie Sylor-Miller, Keavy McMinn, Silvia Botros

The Architect title has fallen out of style in many companies, but the Architect role remains alive and well for folks operating at Staff-plus levels. Architects are responsible for the success of a specific technical domain within their company, for example the company’s API design, frontend stack, storage strategy or cloud infrastructure. For a domain to merit an Architect, it must be both complex and enduringly central to the company’s success.

There is a toxic perception that Architects design systems in isolation, pass their designs to others to implement, and mandate their adoption, but that reciting that stereotype would slander the successful architects I spoke with. Instead, they dedicated their energy to maintaining an intimate understanding of the business’ needs, their users’ goals, and the relevant technical constraints. They wielded that insight to identify and advocate for effective approaches within their area of focus, leading constellations of teams despite limited tailwinds from bestowed organizational authority.

The Architect role tends to evolve in relatively large companies or companies that struggle to hire senior talent early on and later attempt to compensate for a less experienced team with one or two senior hires. Some companies push for Architects to remain deep in the codebase, and others set a clear expectation that Architects must not write code: both models work for some companies.

Examples: Nelson Elhage

The Solver is a trusted agent of the organization who goes deep into knotty problems, continuing to work on them until they’re resolved. Folks in this role are moved onto problems identified by organizational leadership as critical and either lacking a clear approach or with a high-degree of execution risk.

Where most Staff-level roles require a very heavy dose of organizational wrangling, the Solver generally operates on problems that are already identified as organizational priorities, and thus are called on to do relatively little org-level chiropractics. On the other hand, they generally stop working on problems once they’re contained, which can create the feeling of transience, and requires a soft touch to avoid infuriating the teams left behind to maintain the “solved” problem.

The Solver is most common in companies with a weak concept of team, where team sprints are displaced by a lightly directed anarchy. In such companies, it’s common to see the Solver become prevalent in the place of the Team Lead. You’re less likely to encounter this role at traditionally managed sprint-centric companies until those companies become relatively large or long-lived enough to acquire their own varietal of technical debt.

Examples: Michelle Bu, Rick Boone

The Right Hand is the least common of the archetypes, showing up as an organization reaches one thousand or more engineers, and is akin to operating as a senior organizational leader without direct managerial responsibilities. Rick Boone compared his role to the Hand of the King in Game of Thrones and Leo McGarry from The West Wing, operating with the borrowed authority of a senior leader. However borrowing authority comes with the obligation of remaining deeply aligned with that leader’s approach, beliefs and values.

Folks in this role attend their leader’s staff meetings, and work to scale that leader’s impact by removing important problems from their plate. Problems addressed at this level are never purely technical, and instead involve the intersection of the business, technology, people, culture, and process. Right Hands often dive into a fire, edit the approach, and delegate execution to the most appropriate team, and then pop over to the next fire elsewhere in the organization. The joy of these roles is that you only work on the most important problems. The tragedy is that you’re always on to the next issue by the time those problems are truly solved.

In the archetype descriptions I’ve mentioned the weak and strong team concepts, which aren’t common terms and deserve to be expanded upon a bit. A strong team concept is one where ownership, work and accountability is generally assigned to teams. Signs of a strong concept are sprints, story points, tracking tickets, SLAs and goals. A weak team concept is one where most work is assigned to individuals and work is driven primarily through interpersonal connections rather than process.

Because teams serve as an abstraction for organizational leaders, almost all companies move towards a strong team concept after they reach a couple dozen engineers, but some companies manage to evade the specter of process for considerably longer.

As you think about which of these archetypes would fit you, you have to first consider which roles are available within your company, and second reflect on the kind of work that energizes you.

All companies develop a need for engineers who can fill the Tech Lead role, which makes it the best entry archetype to Staff engineering. Companies with weak team constructs often develop the Solver early, whereas companies that operate under strict sprints or agile methodologies tend to develop that role late, if ever. In the recent crops of fast growing technology companies, the Architect and _Right Hand_roles have generally emerged as the organizations reached one hundred and one thousand engineers respectively, and simply don’t exist beforehand. Companies with other strains of cultural DNA often develop them earlier, or sometimes never.

Success in these roles requires remaining engaged, which makes it important to spend time understanding what kinds of work energize you. The Team Lead and Architect tend to work with the same people on the same problems over the course of years, developing a tight sense of team and shared purpose. Some months their focus will be a top company priority, and sometimes they’ll be humming along so well that executives forget your team exists.

The Solver and Right Hand bounce from fire to fire, often having more transactional interactions with the folks they’re working with on any given week. They’re tightly aligned with executive priorities and are likely to receive recognition for addressing leadership’s most pressing problems. On the other hand, while they’ll nominally be on a team with other folks, there will generally be little-to-no overlap within their team’s areas of focus, and they’ll often have a limited sense of community.

For each archetype, you’ll find folks who love it and find it deeply rewarding, along with folks who find the work despair-inspiring. While it’s important to aim towards an archetype that fits you well, it’s also worth remembering that over your thirty or forty year career, you’ll have long enough to spend some time sampling every archetypes.